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Abstract 


We describe Edse, a model-based event-driven simulator implemented for Selmon, a 
tool for sensor selection and anomaly detection in real-time monitoring. The simulator 
is used in conjunction with a causal model to predict future behavior of the model from 
observed data. The behavior of the causal model is interpreted as equivalent to the 
behavior of the physical system being modeled. 

This report provides an overview of the functionality of the simulator and the model- 
based event-driven simulation paradigm on which it is based. Included are high-level 
descriptions of the following key properties: event consumption and event creation, 
iterative simulation, synchronization and filtering of monitoring data from the physical 
system. Finally, we discuss how Edse stands with respect to the relevant open issues of 
discrete-event and model-based simulation. 
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1 Introduction 


This report describes Edse (event-driven simulation engine), a model-based event-driven 
simulator implemented for the Selmon (selective monitoring) tool [Chien et al., 1992; 
Doyle et al., 1992]. In SELMON, the simulator is used in conjunction with a causal model to 
predict future behavior of a physical system from observed data. Observations of physical 
system behavior are possible because the system is monitored by a set of sensors. 

These predictions can be used in two ways: First, current data can be used to predict 
future performance of the system. When predictions about the system turn out to be 
different from the actual performance of the modeled system, the predictions may be 
interpreted as discrepancies [Doyle et al., 1989; Dvorak & Kuipers, 1989]. Second, the 
model can be used to determine whether future performance of the modeled system will 
exhibit certain critical qualities (e.g., cascading alarms). 

The focus of this report is to describe the SELMON simulator EDSE. The core principles 
of Edse are inherited from event-driven simulation [Banks & Carson, 1984]; the target ap- 
plication domains originate in model-based reasoning of physical systems [Hayes, 1989]. 
Applications of model-based simulation are described elsewhere [Chien et al., 1992], Ad- 
ditionally, there are other model-based simulation paradigms, such as total envisionment 
(which generates all possible states and state transitions of the system [Forbus, 1984]) and 
attainable envisionment (which generates the possible behavior histories of a system from 
a given state [Kuipers, 1986]). 

This report provides an overview of the functionality of Edse and the model-based 
event-driven simulation paradigm on which the simulator is based. It is intended to 
describe at a high level the key properties and algorithms of Edse. Supplementary infor- 
mation about building causal models with the modeling language Edsel can be found in 
[Charest, 1992]. 

The rest of this report is organized as follows: Section 2 describes the overall architec- 
ture of the simulator. Section 3 describes synchronization and filtering techniques relevant 
to systems monitoring. Section 4 outlines how EDSE stands with respect to open issues 
of discrete event simulation and model-based reasoning. Section 5 summarizes the main 
features of Edse. 


2 Architecture of EDSE 

Edse allows Selmon to make predictions about the future performance of a monitored 
system by applying current data values to a model of the system. Specifically, the simulator 
uses: 

• A behavioral model of the monitored system 

• The current state of the monitored system at time T 

• A future time V 

to determine the predicted state of the monitored system at time T . More specifically, the 
state of the monitored system is represented by two types of information: 
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1. A set of quantities representing the current values for physical quantities at various 
locations in the system. 

2. An agenda of events which represent changes in quantities that are expected to occur 
in the future. 

Briefly, an event is a 5-tuple e = ( m,q,v,<f>,T ) describing that a mechanism m fired at 
time 4> to set a quantity q to a value v at time t. An event is said to be created at time (f) 
and matured at time r. An agenda is simply a queue ordered by increasing values of r . 
Mechanisms are described below. 

With respect to the event-driven simulation paradigm [Banks & Carson, 1984], the 
simulated objects are quantities in Edse. Message events are restricted to passing from 
one quantity object to another as long as the latter quantity interacts with the former via a 
mechanism. The application of Edse to a specific physical system requires the definition of 
a causal model - that is, a network of quantities interacting via mechanisms (see [Charest, 
1992] for details). The mechanism interactions implicitly define all of the possible events 
that can occur during simulation. 

The simulation process is characterized by two phenomena: event consumption and 
event creation. Event consumption occurs when the current time matches the time of one 
or more events on the agenda. In this case the appropriate quantities are set to the values 
prescribed by the event(s). Event creation occurs when quantities in the model change. 
When a quantity in the model changes, all mechanisms associated with the quantity 
are evaluated and thereby may cause new events to be added to the agenda. Event 
consumption therefore induces event creation, and vice versa. In general, simulation 
consists of quantity changes, followed by mechanism evaluation (event creation), followed 
by more quantity changes (event consumption), and so on. 

Interactions among quantities are modeled by mechanisms. A mechanism is a 4-tuple 
m = (7, 7, <5, q ) describing how a set of input quantities 7 determines the value of an output 
quantity 1 q via the transfer function 7 and delay function <5. Thus, the mechanism specifies 
when (through 7 and 5) and how (through 7 and 7) changes will occur for a quantity q. 

During the event consumption phase of simulation, if a quantity q changes value then 
all the mechanisms that use q as an input will be triggered for the next event creation phase. 
That is, each mechanism m! = (7', 7, <5, q'), where q e 7', will be marked in such a way that 
an event will be created for the mechanism m' during the ensuing event creation phase. 
An event e is created for each triggered mechanism by evaluating or firing the functions 7 
and 8 with respect to input quantities 7 and the simulation time <f>. When these functions 
are fired the mechanism itself is also said to be fired. The resulting event e is described by 
the 5-tuple (rn, q, v, 4>, t ) where v is the result of firing 7 and t is the result of firing 8. 

’To simplify explanation in this report, we assume a single output quantity for each mechanism. The 
newest version of Edse allows multiple output quantities and conditional mechanisms. For practical 
purposes, providing multiple output quantities on a single mechanism allows the same behavior as would 
constructing an identical mechanism for each output quantity. Conditional mechanisms specify conditions 
over the set of input quantities I. These conditions must be satisfied in order for the mechanism to be fired. 
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2.1 Event Consumption and Event Creation 

The simulation is defined by the event consumption and creation processes. We now 
focus upon the details of these two processes. This section describes when event creation 
and event consumption occur in the simulation algorithm. 

Event consumption 

An event c = ( m , <7, v new , 4>, r) is consumed when its maturation time r coincides with 
the current simulation time T. The processing of c consists of replacing the old value 
v Md = V(q,T - 1) with the new value v new indicated by the event. If v old is different 
from v new in the appropriate quantitative or qualitative sense then the event is propagated 
by triggering every mechanism m such that q is an input quantity of m. Figure 1 is a 
pseudo-code description of the event consumption algorithm. 

Event creation 

Events are created when the simulator fires the triggered mechanisms. At that time, the 
transfer function 7 and delay function 6 of each triggered mechanism m = (/, 7, 6, q ) are 
evaluated to create an event e = (rn, q, v , 0, r) where </> is the current time, r = 6(1, 4> ), and 
v = 7(7, <fi). The maturity of this event is either delayed until r or immediate, according 
to the type of delay function 5. Figure 2 is a pseudo-code description of the event creation 
algorithm. 

There are two types of mechanism delay functions: explicit zero and implicit future. An 
implicit future delay function means that the evaluation of the delay function will yield a 
positive event delay. Currently, the event consumption algorithm forces all implicit future 
delay functions to produce values that are at least one simulation timestep later than the 
current simulation time. 2 This restriction allows the simulator to determine when event 
consumption is complete for the current simulation time and therefore when the event 
creation phase can start. 

An explicit zero delay function means that whenever a mechanism is triggered at a 
given simulation time T the mechanism will also be fired at T . Practically, this means that 
during the event consumption phase, quantity value changes can lead some mechanisms 
to be triggered and then immediately fired, thus interleaving event consumption and 
event creation within a single simulation timestep. 

2.2 Event Processing 

The simulator is started at a time T 0 , with the directive to run iteratively to a new time T N . 
The simulator consumes and creates events on a global agenda. Figure 3 is a pseudo-code 
description of the algorithm for processing one timestep during simulation. For each 
timestep T such that T 0 <T <T N , EDSE performs the following actions: 

implementation note: Each simulation timestep corresponds to 1 second of real time for the simulated 
system. 
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Given an agenda of events A 

and the current simulation time T 

Let M - 0 

For each event c^A, 

Let c = (in, q,v ne , „,<}), t) 

Let v 0 i d = V(q,T- 1) 

I f ^ new Void then 

Assign V(q,T) the value v new 

For each mechanism m' — (/', 7 , <*>, q') where q € /' 
Trigger m' 

Add m' to M 

Return the set of triggered mechanisms M 


Figure 1 : Event consumption in EDSE. 


1 . Consume all events scheduled to mature during the current timestep. This action 
includes triggering mechanisms whose input quantities have changed. 

2. For each explicit zero delay mechanism in the set of triggered mechanisms, create an 
event that will mature during the current timestep and immediately fire the transfer 
function to compute the new quantity value. 

3 . If there are still events scheduled to mature during the current timestep then go to 
step 1. Otherwise, go to step 4. 

4. For each implicit future delay mechanism in the set of triggered mechanisms 3 fire 
the transfer and delay functions and then create an event that matures according to 
the result of the delay function. 

5. Schedule the new events according to their maturity. 

6 . Increment the simulation time 4 T. 


3 Synchronization and Filtering 

It is difficult to ensure that a causal model used with EDSE will predict the behavior of 
the physical system with perfect accuracy. This lack of model perfection manifests itself 

technically, at this point in the algorithm all of the triggered mechanisms must be implicit future delay 
mechanisms. 

4 The next simulation time is defined by the maturation time of the next event (if any) in the agenda. 
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Given a set of triggered mechanisms M 
and an agenda of events A 
and the current simulation time T 

For each mechanism m € M 
Let m = (/, 7 , < 5 , q) 

Fire 7 and assign the result to v 
Fire 6 and assign the result to r 
Schedule the event e = (m, q,v, T, t) on A 


Figure 2: Event creation in Edse. 


Given an agenda of events A 

the current simulation time T 

Let M = 0 

Let At Q A such that e G At 

is an event scheduled to mature at T 
While At £ 0 

Remove an event e from At 
Consume the event e 

Collect the resulting triggered mechanisms into M 
Let Mt Q M such that m € Mr 

is an explicit-zero delay mechanism 
For each mechanism m € Afr 

Create an event e = (m, < 7 , v, T, T) 

Add e to At 

For each mechanism m € M. — Mt 

Create an event e = (m, q, v, T, r) where t>T 


Figure 3: Processing a single timestep in EDSE. 


as discrepancies between actual sensor data and the model predictions. Left unchecked, 
these discrepancies may grow so large as to make model predictions useless. In order to 
avoid this phenomenon, the SELMON simulator periodically synchronizes the simulation 
state with observed sensor values. 
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Synchronization is a method of aligning the values of quantities in the model with 
observed sensor values. That is, we explicitly assign the observed sensor values to the 
appropriate quantities. This method assumes that we have reasonable confidence in the 
sensor data. As an alternative, arbitrary user-specified functions can be used to access 
past sensor values and values of other sensors to determine the synchronized value. 
This synchronization occurs immediately before we begin the event processing algorithm 
described in Figure 3 . 

Unfortunately, synchronization in SELMON is incomplete in the sense that the model 
state is not completely synchronized. Only the quantity values are set to their correspond- 
ing sensor values. Ideally, events in the agenda would also be recomputed to reflect the 
new sensor readings. 

Another difficulty with synchronization is sensor noise. If sensor noise causes a sensor 
to incorrectly report an anomalous value, synchronization may cause the model to predict 
discrepant behaviors. In order to minimize this phenomenon, the simulator provides a 
filtering protocol to decrease the impact of spurious sensor readings for particularly noisy 
sensors. 

The filtering protocol allows each sensor .s that is associated with a quantity q in 
the model to have its data values explicitly filtered as they are observed (i.e., before 
synchronization). Filtering is accomplished by means of a function which transforms 
a "raw" data value to the appropriate "filtered" value. Filter functions may perform 
arbitrary transformations of raw data values, using the entire history of raw values for a 
particular sensor as input. Typically, filtered values are the result of calculating a weighted 
average of the last few raw data values. 

The filtering protocol implemented in EDSE is subject to the following caveats: 

• If a sensor does not report a raw value, the sensor filter will generate a filtered value 
for the sensor anyway. It has been noted that only those sensors which have reported 
a value should be used to synchronize the model. 

• Consider a model where a quantity q\ is associated with a sensor .si and q 2 is asso- 
ciated with a sensor s 2 . If there is a zero-delay mechanism m 12 from q\ to q-i, it has 
been noted that the mechanism m 12 should not be used to infer a new value for q 2 
but rather the value of s 2 should be used. This is consistent with the principle of 
"trusting" the data as much as possible. 

4 Open Issues 

EDSE is subject to the open issues typical of discrete event simulation in general and 
model-based simulation in particular. This section describes what these issues mean for 
Edse and, when applicable, what steps can be taken to address them. 

Race conditions 

A race condition occurs when two events e\ and e 2 occur at the same simulation time 
T and they both change the same quantity q. Which of the two event values (vj from ej or 
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v 2 from c 2 ) should be used to determine the value of the quantity V(</, T)? Alternatively, 
should ej and c 2 be fused to form a new event e li2 such that c ]>2 would be used instead of 
and c 2 to change q ? Such race conditions can potentially occur with implicit future and 
explicit zero delays in any combination. 

Currently, events are processed iteratively, one at a time (i.e., the simulation is sequen- 
tial). This means that V{q, T ) will be the value of the last event occurring at T that affects 
q. This is a source of indeterminism in the simulation. In some cases of zero-delay events, 
the race condition can be avoided by imposing constraints on the model (see below). 

A better solution would fuse all of the events that occur at the same time and af- 
fect the same quantity. This poses two problems. First, race conditions are generally 
unpredictable; therefore, when one is detected, it may be necessary to "undo" some com- 
putations, solve the race condition, and proceed again. Research in operating systems 
addressed this problem by introducing the concept of virtual time [Jefferson, 1985; Jeffer- 
son et al., 1987], where the operating system allows independent processes to pursue their 
computations, even though enforcing global consistency may force them to backtrack and 
resume from an earlier state. 

Second, race conditions are typically an artifact of the modelling language: some events 
are defined to occur simultaneously because they are at the smallest granularity of the time 
scale. A smaller set of race conditions comes from events occurring at different instants but 
processed at the same time because of discretization. In either case, the resolution of race 
conditions ultimately depends on a physical interpretation of the underlying phenomena. 
In practice, we expect that prioritizing events (see below) will be sufficient in most cases. 

Future events 

When the delay function of an implicit future delay mechanism evaluates to zero, the 
mechanism should be treated as an explicit zero delay mechanism. Currently, this issue 
is avoided since implicit future delays are forced by the simulator to be at least as large 
as one timestep. For the simulation of physical systems, this is not an issue as long as a 
minimum time scale can be attributed to the underlying continuous physical phenomena 
being modeled. 

Zero-delay events 

From a modeling standpoint, there are roughly two classes of mechanisms used to 
model a physical system. The first class encodes the dynamics of the continuous physical 
phenomena occurring in the system. The second class encodes the discrete control changes 
that occur in the system. The former class of mechanisms typically has implicit future 
delays since continuous physical phenomena take some time to propagate or produce any 
effect. The latter class of mechanisms typically has explicit zero delays since control actions 
are discrete and instantaneous relative to the continuous physical phenomena. However, 
there is an implicit sequentiality in the simulation of explicit zero events due to the actual 
propagation of these events in the network of mechanisms. This sequential propagation 
of zero-delay events defines an artificial time scale that has no physical support; it is an 
example of "mythical time"[de Kleer & Brown, 1984] in qualitative simulation. 

The simulator introduces mythical time as it processes all the zero delay events in 
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some order before processing any future delay event. Currently, there is no provision 
in the simulator to provide the user with control over the ordering of zero-delay events; 
nevertheless, they are processed on a first-come first-served basis. To avoid race condition 
problems, the modeling language may be augmented to force an a-priori order of process- 
ing for mythical time. One approach would be to construct a list of zero-delay event types 
defining a partial ordering in mythical time. This partial ordering would be enforced by 
the simulator such that all zero-delay events of higher priority would be processed before 
zero-delay events of lower priority until quiescence. 3 This partial ordering of zero-delay 
events does not solve the problem entirely: race conditions can still occur with zero-delay 
events of the same priority. However, it does prevent race conditions across priority 
levels. To that extent, it may be sufficient for a modeler to use this partial order to avoid 
race conditions. 

Causal consistency 

To obtain accurate model predictions, it is necessary that the model reflect in its state 
information the actual physical processes occurring in the physical system. Noisy data 
and numerical errors, in particular, are typical factors leading to errors in state information. 
Since the local scope of the models is narrowed down to components, such errors in state 
information can result in globally inconsistent states. 

For example, a fluid pipe is not always modelled as one component. Take the case 
when a membrane pressure sensor is mounted on such a pipe. Then, the global model of 
the pipe consists of three pipe models, and the middle one doubles as a pressure sensor 
model. In these circumstances, a flow of small magnitude through the global pipe model 
can well be tainted with round-off errors such that the flows in each of the three pipes are 
not in the same global direction; this is a clear case of global model inconsistency despite 
locally consistent models of the constituent components. 

Recently, Forbus and Falkenhainer [1992] addressed this issue by adding a self- 
monitoring module to their numerical simulators. The task of the self-monitoring module 
is to detect and steer the simulation away from globally inconsistent states. 


5 Summary 

The Selmon simulator Edse uses an event-driven paradigm to generate predictions of 
future physical system performance from a model of the physical system and informa- 
tion about the current system state. These predictions can be used to detect potential 
discrepancies or to determine if future system behavior will exhibit critical qualities. 

Model drift can cause a reasonably faithful model to eventually diverge from actual 
system behavior over time. In order to deal with this issue, EDSE synchronizes the model 
with observed sensor data. Also, filtering is used to deal with noisy data in some cases. 
Several problem issues remain open in the current Edse implementation. 

’’Here, quiescence at a given priority means all zero-delay events of that priority have been processed 
and that all the zero-delay events created in the meantime have a lower priority. 
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Appendix: Edse Source Code 

The following program listing presents the Lisp source code for a possible implemen- 
tation of Edse. The function simulate is the sole entry-point to the simulator. All of 
the necessary data structure definitions (e.g., event, agenda) and some of the support 
function definitions have been omitted in the interest of space. 

(defun current-event (agenda timestamp) 

"Return the first event on the agenda if it is scheduled 
to happen on or after the given timestamp.” 

(declare (type agenda agenda) 

(type fixnum timestamp) 

(values (or event nil))) 

(loop for current-event in (events-of agenda) 
if (null-event-p current-event) 
do (error "The agenda is empty.") 
if (< (maturity current- event ) timestamp) 
do 

(cerror "Ignore the mis - scheduled event." 

"Current time is ~a . ~(3 
Event ~a is scheduled to occur at ~a . " 
timestamp 

( name current -event ) 

(maturity current - event ) ) 

(warn "Skipping event ~a . " 

(name current -event ) ) 

(pop (events-of agenda)) 

(deal locate -event current -event ) 

else return current-event 

finally (error "The agenda is empty."))) 

(defun split-agenda (agenda timestamp) 

"Split the agenda with respect to the given timestamp. 

Return two subagendas: events maturing at timestamp 
and events maturing after timestamp." 

(declare (type agenda agenda) 

(type fixnum timestamp)) 

(loop with mature-events = (events-of agenda) 
initially 

(unless (equal* (maturity (first (events-of agenda))) 
timestamp) 

(error "Malformed agenda: the maturity of the ~ 
first event was expected to be ~d . " 
timestamp) ) 

for split on (events-of agenda) by # ' cdr 
as (first second . rest) = split 

while (and second (equal* (maturity second) timestamp)) 
finally 
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(shiftf (events-of agenda) (rest split) nil) 
return (values (make-agenda mature - events ) agenda))) 

(defun schedule (pending-events agenda) 

"Merge the pending-events into the agenda." 

(declare (type agenda pending-events agenda) 

(values agenda ) ) 

(merge ' list 

( events -of agenda ) 

(sort pending-events #'< : key # 'maturity) 

#'< : key # 'maturity) 

agenda ) 

;;; Pend ing - mechan isms are passed in as a performance hack: 

; ; ; PUSHNEW can be used to optimally add only those 
;;; mechanisms which are not already on the list. 

(defun mature (agenda pending-mechanisms timestamp) 

n Pass the value of each event to the appropriate quantities 
and mark as pending all of the output mechanisms from 
those quantities . TT 
(declare (type agenda agenda) 

(type pending -mechanisms ) 

(type fixnum timestamp) 

(values immediate-mechanisms pending-mechanisms) ) 
(loop with immediate -mechanisms - nil 
for event in (events-of agenda) 

do (loop for quantity in (outputs (mechanism event)) 
as change-p * (not (equal* (value quantity) 

(value event ) ) ) 

when change-p 

do (loop for mechanism in (outputs quantity) 
if ( immediate-mechanism-p mechanism) 
do (pushnew mechanism 

immediate -mechan isms 
: test #'eq) 

else do (pushnew mechanism 

pending -mechan isms 
: test # 'eq) ) 

; ; unconditionally 

do ( setf (value quantity) (value event) 

(timestamp quantity) timestamp)) 
finally return (values immediate-mechanisms 

pending-mechanisms) ) ) 

(defun propagate (pending-mechanisms timestamp) 

"Create and return a list of events from the given 
pending mechanisms . n 
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(declare (type list pending-mechanisms) 

(type fixnum timestamp) 

(values pending -events ) ) 

(loop for mechanism in pending -mechan isms 

when (compute-context-match mechanism timestamp) 
collect (allocate-event mechanism timestamp))) 

( def un simulate- immediate -events (agenda timestamp) 

"Consume all of the events on the agenda which mature at 
the given timestamp. 1 ’ 

(declare (type agenda agenda) 

(values agenda pending -mechan isms ) ) 

(loop with immediate-agenda 

and immediate -mechanisms 
and pending-mechanisms = () 
and pending -events 
initially 

(multiple- value- setq ( immediate -agenda agenda ) 
(split-agenda agenda timestamp)) 
do 

(multiple- value- setq 

( immediate-mechanisms pending-mechanisms ) 

(mature immediate-agenda pending-mechanisms 
timestamp ) ) 

( deallocate - agenda immediate- agenda ) 
while (and immediate-mechanisms 
(setq pending-events 

(propagate immediate-mechanisms 
timestamp) ) ) 

do (setq immediate-agenda 

(make-agenda pending-events)) 
finally return (values agenda pending -mechan isms )) ) 

(defun simulate (instant limit disposition) 

"Consume events from the global *agenda* until the 
limit is reached." 

(let ((timestamp (time instant)) 

( iterations 0 ) ) 

(flet ((time-limit () 

(> timestamp limit)) 

( iter at ions -limit ( ) 

(> iterations limit))) 

(loop with limit-p = (ecase disposition 

( : time # ' time- limit ) 

( : iterations # ' iter at ions - 1 imit ) ) 
and pending -mechan isms 

as event = ( current - event *agenda* timestamp) 
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while event 
do 

(setq timestamp (maturity event)) 

(incf iterations) 
until (funcall limit-p) 
do 

(multiple* value -setq 

( * agenda* pending -mechanisms ) 
(simulate- immediate -events * agenda* 

timestamp ) ) 

( schedule ( propagate pen ding -mechanisms 

timestamp) *agenda* ) 
finally return *agenda*)))) 
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